In computer programming, the scope of a variable is the code region in which the variable is available to use. For example, a particular variable may be in scope for a particular code segment or code region. As used herein, a “code segment” is a statement, expression, or any other type of code segment (or a portion thereof) to which scoping rules apply. A “code region” is a block, method, function, class, package, module, application, or any other type of code region that encloses one or more code segments. Scoping is a process of determining the scope(s) in which one or more variables are available to use. Specifically, in an embodiment, scoping determines the scope(s) of variable(s) in code where one sequence of code segments encapsulates one or more other sequences of code segments. Different programming languages have different rules for scoping variables. In general, there are two types of scoping: dynamic scoping and lexical scoping, as described in further detail below.
Typically, in dynamic scoping, a variable is in scope until the function in which the variable was declared returns. For example, suppose a function ƒ( ) declares a local variable x in one code segment and then calls another function g( ) in a subsequent code segment. At runtime, x is in scope for all code segments in ƒ( ) following the code segment that declares x, both before and after calling g( ). However, when g( ) is called from within ƒ( ), x also is in scope for all code segments in g( ), because ƒ( ) has not yet returned at the time g( ) is called. In other words, when g( ) is called from within ƒ( ), the scope of g( ) is inclusive of the scope of ƒ( ). In a typical dynamically scoped programming language, if g( ) declares another local variable also called x, then the g( )'s variable x overrides ƒ( )'s variable x until g( ) returns.
Typically, in lexical scoping, also referred to as static scoping, a variable's scope depends on the lexical environment in which the variable is declared, subject to the particular programming language's scoping rules. In a typical lexically scoped programming language, variables declared in methods are considered local variables. For example, suppose a method ƒ( ) declares a variable x in one code segment and then calls another method g( ) in a subsequent code segment. Because x is local to ƒ( ), it is not necessary to compile or execute the application to know that x is not in scope for any code segments in g( ). In other words, the scope of g( ) is not inclusive of the scope of ƒ( ). Similarly, when a code segment in a method is used to instantiate an object, the scope of code segments within the newly instantiated object is not inclusive of the scope of the method in which the object was instantiated. However, the scope of a block in a method typically is inclusive of the scope of preceding top-level code segments in that method.
Typically, the scope of a variable depends on the code region where the variable is declared. A variable declared in a method may be in scope for subsequent code segments within the method, but not for code segments located outside of the method, such as in different methods in the same class or in another class. A variable declared within a block may be in scope for subsequent code segments located within the block, but not for code segments located outside of the block. In some object-oriented programming languages, when a variable is declared in a class but outside of a method, keywords may be used as access modifiers, to make the variable accessible at the class, subclass, package, or application level(s). For example, versions of the Java programming language include the access modifiers public, protected, and private. The absence of an access modifier may imply a default access level. For example, a variable declared in a class but outside of a method, without an explicit access modifier, may be accessible by the class and its containing package only.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.